Many companies and other organizations operate computer networks that interconnect numerous computing systems to support their operations, such as with the computing systems being co-located (e.g., as part of a local network) or instead located in multiple distinct geographical locations (e.g., connected via one or more private or public intermediate networks). For example, data centers housing significant numbers of interconnected computing systems have become commonplace, such as private data centers that are operated by and on behalf of a single organization, and public data centers that are operated by entities as businesses to provide computing resources to customers. Some public data center operators provide network access, power, and secure installation facilities for hardware owned by various customers, while other public data center operators provide “full service” facilities that also include hardware resources made available for use by their customers. However, as the scale and scope of typical data centers has increased, the tasks of provisioning, administering, and managing the physical computing resources have become increasingly complicated.
The advent of virtualization technologies for commodity hardware has provided benefits with respect to managing large-scale computing resources for many customers with diverse needs, allowing various computing resources to be efficiently and securely shared by multiple customers. For example, virtualization technologies may allow a single physical computing machine to be shared among multiple users by providing each user with one or more virtual machines hosted by the single physical computing machine. Each such virtual machine may be regarded as a software simulation acting as a distinct logical computing system that provides users with the illusion that they are the sole operators and administrators of a given hardware computing resource, while also providing application isolation and security among the various virtual machines.
As demand for virtualization-based services at provider networks has grown, more and more networking and interconnectivity-related features have been added to the services. Many such features may require network packet address manipulation in one form or another, e.g., at level 3 or level 4 of the open systems interconnect stack. For example, some providers configure groups of resources as isolated virtual networks on behalf of respective customers, with substantial flexibility being provided to the customers with respect to the networking configuration details within their particular subsets of the provider network resources. As customers may assign IP (Internet Protocol) addresses within their isolated virtual networks independently of the addresses assigned at other isolated virtual networks, managing traffic in and out of the isolated virtual networks may require the use of address translation techniques. For some types of applications which may be deployed at such isolated virtual networks or at other platforms, successive requests from a given client of a given application should ideally be directed using packet header manipulation to the same back-end server, further complicating the packet processing requirements. For other applications, it may be useful to obfuscate at least some of the source address information contained in a set of packets in a consistent manner, or to replicate contents of the packets among many different recipients according to specified rules or directives. Using ad-hoc solutions for all the different types of packet transformation requirements may not scale in large provider networks at which the traffic associated with hundreds of thousands of virtual or physical machines may be processed concurrently.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.